3단계에서 4단계로 요구사항이 변경될 때 로또를 생성하는 부분의 요구사항만 변경됐다.
로또를 생성하는 부분을 다음과 같은 구조의 인터페이스로 분리해 보는 연습을 해보면 어떨까?
이와 같이 인터페이스로 구현했을 때의 잇점에 대해 고민해 보는 시간을 가져본다.
Lottos는 사용자가 구매한 n장의 로또를 추상화한 객체임

public interface LottosGenerator {
    Lottos generate();
}

2. 자동 개수와 수동 개수
   자동 개수는 전체 로또 개수에서 수동 개수를 빼서 구하는 작업을 필요할 때마다 수행하고 있는데 이 방법보다는 전체 로또 개수, 자동 개수, 수동 개수를 각각 가지고 있는 것이 나을까요?

이 구조로 리팩터링하면서 위 질문에 대한 답도 스스로 찾아볼 것을 추천해 본다.

이 값을 출력하기 위해 이 객체의 인스턴스 변수로 totalCount, manualCount를 필드로 가지는 것은 좋은 선택으로 보이지 않음.
UI에 출력하기 위해 문자열을 생성하는 책임을 View 객체가 담당하도록 구현하는 것은 어떨까?

👍

Controller의 역할은 View와 Model(도메인 객체)를 연결하는 역할이 주이다.
그런데 이 객체의 역할을 보면 Controller 역할은 보이지 않는다.
객체 이름에서 Controller 이름을 빼고, 이 객체의 역할을 LottoCount가 담당하도록 구현하는 것은 어떨까?
LottoCountController라는 이름을 부여하는 순간 LottoCount 객체를 수동적인 존재로 바라보는 느낌이 듦

ManualLottoMachine 이름을 부여했다면 이 객체의 이름은 AutoLottoMachine으로 부여하는 것이 좋지 않을까?

자동과 수동 로또를 생성하는 부분의 로직이 Controller라 할 수 있는 main() 메서드에 집중되어 있는 느낌이 든다.
자동과 수동 로또 수를 결정하고, 각각의 로또를 생성한 조합하는 역할을 다른 객체를 추가해 위임할 수도 있다.

이와 같이 인터페이스를 구현하고, 구현체가 서로 연결되어 있는 경우 아래와 같은 구현체를 통해 구현체를 통합할 수 있음.
보통 디자인 패턴에서 컴포지트 패턴으로 알려져 있음.
아래와 같은 객체 추가에 따른 효과를 느껴 봤으면 하는 바람으로 피드백 남겨봄.

public class LottosBundleGenerator implements LottosGenerator {
    private final List<LottosGenerator> lottosGenerators;

    public LottosBundleGenerator(Money money, List<String> manualLottoText) {
        this(toLottosGenerators(money, manualLottoText));
    }

    private static List<LottosGenerator> toLottosGenerators(Money money, List<String> manualLottoText) {
        // manualLottoText 활용해 ManualLottosGenerator 생성
        // money에서 수동으로 구매한 로또 수 만큼 차감한 후 AutoLottosGenerator 생성
    }

    public LottosBundleGenerator(List<LottosGenerator> lottosGenerators) {
        this.lottosGenerators = lottosGenerators;
    }

    @Override
    public Lottos generate() {
        // List<LottosGenerator> 반복문 돌며 로또 생성
        return 두 로또를 합쳐서 반환;
    }
}

manualLottoText 크기가 manualCount인데 manualCount는 필요없는 값이지 않을까?